Internet Info 1994 March

home *** CD-ROM | disk | FTP | other *** search

/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / internet-drafts / 1id-abstracts.txt < prev next >

Wrap

Text File | 1993-10-28 | 139.1 KB | 2,509 lines

Current Internet Drafts This summary sheet provides a short synopsis of each Internet Draft available within the "Internet-Drafts" Directory at the NIC and NNSC. These drafts are listed alphabetically by Working Group acronym and initial post date. Internet Message Extensions --------------------------- "The Content-MD5 Header", M. Rose, 04/16/1993, <draft-ietf-822ext-md5-02.txt> This memo specifies an optional header field, Content-MD5, for use with MIME-conformant messages. IP Over AppleTalk ----------------- "AppleTalk Management Information Base II", S. Waldbusser, K. Frisa, 04/30/1993, <draft-ietf-appleip-mib2-01.txt> This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing AppleTalk networks. RFC1243 defines a set of MIB objects for managing the lower layers of the AppleTalk protocol stack, up to the Network layer. This memo defines additional objects that exist in the AppleTalk portion of the MIB. These objects provide for the management of the transport and session layers of the AppleTalk protocol stack, as well as extensions to the lower layers. This is achieved in an upwardly-compatable fashion. "KIP AppleTalk/IP Gateway Functionality", P. Budne, 07/06/1993, <draft-ietf-appleip-kip-gateway-00.txt, .ps> This memo was started as an effort to describe ``IPTalk'' for the AppleTalk-IP Working Group of the Internet Engineering Task Force (IETF). It became apparent that since no protocol standard or description existed that implementation specific information was unavoidable. KIP is the prototypical AppleTalk/IP Gateway implementation and is available in source form. KIP's functionality forms the basis for many commercial products available today. IP Over Asynchronous Transfer Mode ---------------------------------- "Default IP MTU for use over ATM AAL5", R. Atkinson, 10/26/1993, <draft-ietf-atm-mtu-02.txt> This draft discusses the IP MTU for use over ATM Adapatation Layer 5, use of industry-standard ATM signalling mechanisms to negotiate other MTU values for use over a particular ATM circuit, and the use of IP Path MTU Discovery inconjunction with ATM. "Classical IP and ARP over ATM", M. Laubach, 10/15/1993, <draft-ietf-atm-classic-ip-05.txt> This memo defines an initial application of classical IP and ARP in an Asynchronous Transfer Mode (ATM) network environment configured as a Logical IP Subnetwork (LIS) as described in Section 5. This memo does not preclude the subsequent development of ATM technology into areas other than a LIS; specifically, as single ATM networks grow to replace many ethernet local LAN segments and as these networks become globally connected, the application of IP and ARP will be treated differently. This memo considers only the application of ATM as a direct replacement for the "wires" and local LAN segments connecting IP end-stations ("members") and routers. Issues raised by MAC level bridging and LAN emulation are beyond the scope of this paper. This memo introduces general ATM technology and nomenclature. Readers are encouraged to review the ATM Forum and ITU-TS (formerly CCITT) references for more detailed information about ATM implementation agreements and standards. ATM MIB ------- "Definitions of Managed Objects for the SONET/SDH Interface Type", Tracy Brown, Kaj Tesink, 10/07/1993, <draft-ietf-atommib-sonet-01.txt> This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) objects. This document is a companion document with Definitions of Managed Objects for the DS1/E1 and DS3/E3 Interface Types, RFC1406 [14] and RFC1407 [13]. This memo specifies a MIB module in a manner that is both compliant to the SNMPv2 SMI, and semantically identical to the peer SNMPv1 definitions. "Definitions of Managed Objects for ATM Management", M. Ahmed, K. Tesink, 10/21/1993, <draft-ietf-atommib-atm-01.txt> This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing ATM-based interfaces, networks and services. This memo specifies a MIB module in a manner that is both compliant to the SNMPv2 SMI, and semantically identical to the peer SNMPv1 definitions. [Temporary Note: Upon progression of this specification as a Proposed Standard, an SNMPv2 and an SNMPv1 version of this MIB module will be made available to ease migration.] This memo does not specify a standard for the Internet community. Audio/Video Transport --------------------- "Issues in Designing a Transport Protocol for Audio and Video Conferences and other Multiparticipant Real-Time Applications", H. Schulzrinne, 10/21/1993, <draft-ietf-avt-issues-01.txt, .ps> This memorandum is a companion document to the current version of the RTP protocol specification draft-ietf-avt-rtp-*.{txt,ps}. It discusses aspects of transporting real-time services (such as voice or video) over the Internet. It compares and evaluates design alternatives for a real-time transport protocol, providing rationales for the design decisions made for RTP. Also covered are issues of port assignment and multicast address allocation. A comprehensive glossary of terms related to multimedia conferencing is provided. This document is a product of the Audio-Video Transport working group within the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at rem-conf@es.net and/or the author(s). "RTP: A Transport Protocol for Real-Time Applications", H. Schulzrinne, S. Casner, 10/21/1993, <draft-ietf-avt-rtp-04.txt, .ps> This memorandum describes the real-time transport protocol, RTP. RTP provides end-to-end network transport functions suitable for applications transmitting real-time data, such as audio, video or simulation data over multicast or unicast network services. RTP does not address resource reservation and does not guarantee quality-of-service for real-time services. The data transport isaugmented by a control protocol (RTCP) designed to provide minimal control and identification functionality particularly in multicast networks. Within multicast associations, sites can also direct control messages to individual sites. RTP and RTCP are designed to be independent of the underlying transport and network layers. The protocol supports the use of RTP-level translators and bridges. This specification is a product of the Audio/Video Transport working group within the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at rem-conf@es.net and/or the authors. "Media Encodings", H. Schulzrinne, 09/17/1993, <draft-ietf-avt-encodings-02.txt> This document describes a possible structure of the media content for audio and video for Internet applications. The definitions are independent of the particular transport mechanism used. The descriptions provide pointers to reference implementations and the detailed standards. This document is meant as an aid for implementors of audio, video and other real-time multimedia applications. "Sample Profile for the Use of RTP for Audio and Video Conferences with Minimal Control", H. Schulzrinne, 10/21/1993, <draft-ietf-avt-profile-03.txt> This note describes a profile for the use of the real-time transport protocol (RTP) and the associated control protocol, RTCP, within audio and video multiparticipant conferences with minimal control. It provides interpretations of generic fields within the RTP specification suitable for audio and video conferences. In particular, this document defines a set of default mappings from format index to encodings. The document also describes how audio and video data may be carried within RTP. It defines a set of standard encodings and their names when used within RTP. However, the definitions are independent of the particular transport mechanism used. The descriptions provide pointers to reference implementations and the detailed standards. This document is meant as an aid for implementors of audio, video and other real-time multimedia applications. "Packetization of H.261 video streams", T. Turletti, C. Huitema, 06/01/1993, <draft-ietf-avt-video-packet-01.txt> This draft describes a packetization scheme of H.261 video stream. The scheme proposed can be used to transport such a video flow over the protocols used by RTP. This specification is a product of the Audio-Video Transport working group within the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at rem-conf@es.net and/or the authors. Border Gateway Protocol ----------------------- "A Border Gateway Protocol 4 (BGP-4)", Y. Rekhter, T. Li, 06/21/1993, <draft-ietf-bgp-bgp4-06.txt> This document, together with its companion document, "Application of the Border Gateway Protocol in the Internet", define an inter-autonomous system routing protocol for the Internet. "Definitions of Managed Objects for the Border Gateway Protocol (Version 4)", S. Willis, J. Burruss, J. Chu,, 08/24/1993, <draft-ietf-bgp-mibv4-03.txt> This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing the Border Gateway Protocol. "BGP4/IDRP for IP---OSPF Interaction", K. Varadhan, S. Hares, Y. Rekhter,, 09/27/1993, <draft-ietf-bgp-bgp4ospf-interact-02.txt> This memo defines the various criteria to be used when designing an Autonomous System Border Routers (ASBR) that will run either BGP4 or IDRP for IP with other ASBRs external to the AS and OSPF as its IGP. "Application of the Border Gateway Protocol in the Internet", Y. Rekhter, P. Gross, 09/27/1993, <draft-ietf-bgp-application-02.txt> This document, together with its companion document, "A Border Gateway Protocol 4 (BGP-4)", define an inter-autonomous system routing protocol for the Internet. "A Border Gateway Protocol 4 (BGP-4)" defines the BGP protocol specification, and this document describes the usage of the BGP in the Internet. Information about the progress of BGP can be monitored and/or reported on the BGP mailing list (bgp@ans.net). "Application of the Border Gateway Protocol and IDRP for IP in the Internet", Y. Rekhter, S. Hares, 10/18/1993, <draft-ietf-bgp-idrp-usage-00.txt> This document, together with its companion documents, "A Border Gateway Protocol 4 (BGP-4)" and "IDRP for IP", define an inter-autonomous system routing protocol for the Internet. "A Border Gateway Protocol 4 (BGP-4)" defines the BGP protocol specification. "IDRP for IP" defines the use of IDRP for IP in the Internet. The IDRP specification defines the IDRP protocol. This document describes the usage of the BGP and IDRP for IP in the Internet. Information about the progress of BGP can be monitored and/or reported on the BGP mailing list (bgp@ans.net). Information about the progress of IDRP for IP can be monitored and/or reported on the IDRP for IP mailing list (idrp-for-ip@merit.edu). Common Authentication Technology -------------------------------- "FTP Security Extensions", S. Lunt, 10/12/1993, <draft-ietf-cat-ftpsec-03.txt> This document defines extensions to the FTP specification RFC959, "FILE TRANSFER PROTOCOL (FTP)" (October 1985), which provide strong authentication, integrity, and confidentiality on both the control and data channels with the introduction of new optional commands, replies, and file transfer encodings. Chassis MIB ----------- "Definitions of Managed Objects for a Chassis Containing Multiple Logical Network Devices", D. Arneson, 06/24/1993, <draft-ietf-chassis-mib-02.txt> This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. In particular it defines objects for managing a chassis containing multiple (logical) networking devices, such as repeaters, bridges, routers, terminal servers, etc. DECnet Phase IV MIB ------------------- "DECnet Phase IV MIB - Implementation Report", J. Saperia, 06/21/1993, <draft-ietf-decnetiv-mib-implement-00.txt> This memo outlines current implementation experience of the DECnet Phase IV MIB Extensions which are defined in RFC1289. It has been prepared as part of the evaluation process for the movement of the document from Proposed to Draft Standard Status. This memo does not specify a standard for the Internet community. "DECnet Phase IV MIB Extensions", J. Saperia, 10/27/1993, <draft-ietf-decnetiv-mibext-03.txt> Abstract not provided. Domain Name System ------------------ "DNS Support for IDPR", R. Austein, 10/26/1993, <draft-ietf-dns-idpr-02.txt> This note documents the support needed from the Domain Name System (DNS) by Inter-Domain Policy Routing (IDPR). The DNS changes are minor and can be deployed with minimal impact on the installed DNS community. "DNS Resolver MIB Extensions", R. Austein, J. Saperia, 07/19/1993, <draft-ietf-dns-resolver-mib-01.txt> Abstract not provided. "DNS Server MIB Extensions", R. Austein, J. Saperia, 07/08/1993, <draft-ietf-dns-server-mib-01.txt> Abstract not provided. "Incremental Transfer and Fast Convergence in DNS", A. Kumar, S. Hotz, J. Postel,, 10/14/1993, <draft-ietf-dns-ixfr-00.txt> This memo proposes extensions to the DNS protocols to provide for an incremental zone transfer (IXFR) procedure. A companion mechanism, the NOTIFY procedure, is also proposed to allow secondaries to learn of changes to the primary database in a timely manner. Frame Relay Service MIB ----------------------- "Definitions of Managed Objects for Frame Relay Service", T. Brown, 10/14/1993, <draft-ietf-frnetmib-fr-04.txt> This memo defines an extension to the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing the Frame Relay Service. This memo does not specify a standard for the Internet community. "Service Management Architecture for Virtual Connection Services", K. Rodemann, 07/02/1993, <draft-ietf-frnetmib-virtual-sma-01.txt> This document presents the Service Management Architecture, an architectural framework for defining SNMP MIB modules for Customer Network Management (CNM) of network services over connection-oriented networks. The work is motivated by the fundamental differences in management views and functionality between a service provider and a service customer. Differences between service provider and service customer include whole-network vs. network-portion view, direct vs. indirect management, and physical vs. logical view. These fundamental differences suggest a difference in philosophy between Service Management and Device Management. Much work has been done and experience gained in writing Device MIB modules for hands-on management of physical devices, but defining Service MIB modules is a relatively new area and requires the development of a new architectural framework. Internet Architecture Board --------------------------- "The Internet Standards Process -- Revision 2", Internet Architecture Board, Internet Engineering Steer, C. Huitema,, 09/16/1993, <draft-iab-standards-processv2-02.txt> This document is a draft of the first revision of RFC 1310, which defines the official procedures for creating and documenting Internet Standards. This draft revision is being distributed to the Internet community for comments and suggestions. This revision (revision 2) includes the following major changes: (a) The new management structure arising from the POISED Working Group is reflected. These changes were agreed to by the IETF plenary and by the IAB and IESG in November 1992 and accepted by the ISOC Board of Trustees at their December 1992 meeting. (b) Prototype status is added to the non-standards track maturity levels (Section 2.4.1). [Second draft - the text describing the Prototype status is modified.] (c) The Intellectual Property Rights section is completely revised, in accordance with legal advice. Section 5 of this document replaces Sections 5 and 6 of RFC-1310. The new section 5 has been reviewed by legal counsel to the Internet Society. [The first draft of revision 2 contained text that had not been subjected to legal review. The second draft text has undergone legal review, and has been approved by counsel to the Internet Society.] "Liaison between Internet and other standardization agencies", C. Huitema, 06/22/1993, <draft-iab-liaisons-00.txt> The IAB has been working toward establishing a liaison relationship between the Internet Society and the other standards making organization, such as the ISO and the ITU. This memo presents a rationale for establishing such a liaison. It also presents a summary of past actions and a status report on the current progress. "The MultiProtocol Internet", B. Leiner, Y. Rekhter, 10/27/1993, <draft-iab-multiprotocol-00.txt> There has recently been considerable discussion on two topics: MultiProtocol approaches in the Internet and the selection of a next generation Internet Protocol. This document suggests a strawman position for goals and approaches for the IETF/IESG/IAB in these areas. It takes the view that these two topics are related, and proposes directions for the IETF/IESG/IAB to pursue. In particular, it recommends that the IETF/IESG/IAB should continue to be a force for consensus on a single protocol suite and internet layer protocol. The IETF/IESG/IAB should: - maintain its focus on the TCP/IP protocol suite, - work to select a single next-generation internet protocol and develop mechanisms to aid in transition from the current IPv4, and - continue to explore mechanisms to interoperate and share resources with other protocol suites within the Internet. Internet Anonymous FTP Archives ------------------------------- "How to Use Anonymous FTP", P. Deutsch, A. Emtage, A. Marine,, 06/15/1993, <draft-ietf-iafa-howftp-00.txt> This document provides information for the novice Internet user about using the File Transfer Protocol (FTP). It explains what FTP is, what anonymous FTP is, and what an anonymous FTP archive site is. It shows a sample anonymous FTP session. It also discusses common ways files are packaged for efficient storage and transmission. "Publishing Information on the Internet with Anonymous FTP", P. Deutsch, A. Emtage, 08/17/1993, <draft-ietf-iafa-publishing-00.txt> This document specifies a range of information that your site may wish to make available on your Anonymous FTP Archive to the Internet user community. Automatic archive indexing tools have been created that can gather and index this information, thus making it easier for users to find and access it. It also may be used by the general user community for extracting information about the archive itself, or about material contained on the archive. "Data Element Templates for Internet Information Objects", P. Deutsch, A. Emtage, 08/17/1993, <draft-ietf-iafa-templates-00.txt> This document describes full definitions of templates defined in the companion document "Publishing Information on the Internet with Anonymous FTP" and are an initial attempt a providing a consistent naming scheme for indexing information for Internet information "objects" such as documents, services and site information. Integrated Directory Services ----------------------------- "X.500 Pilot Projects", A. Marine, 06/15/1993, <draft-ietf-ids-pilots-00.txt> This document lets people know about three significant X.500-based white pages projects. Each pilot is described briefly, then basic information is provided about how an organization may participate in the pilot and where they should ask for more details. "A Revised Catalog of Available X.500 Implementations", A. Getchell, S. Sataluri, 10/08/1993, <draft-ietf-ids-catalog-00.txt> This document is the result of a survey that gathered new or updated descriptions of currently available implementations of X.500, including commercial products and openly available offerings. This document is a revision of RFC 1292. We contacted each contributor in RFC 1292 and requested an update and published the survey template in several mailing lists and obtained new product descriptions. IETF Steering Group ------------------- "IETF Working Group Guidelines and Procedures", E. Huizer, D. Crocker, 06/17/1993, <draft-ietf-iesg-wgguidelines-01.txt, .ps> The Internet Engineering Task Force (IETF) has the primary responsibility for developing and review of specifications intended as Internet Standards. IETF activities are organized into Working Groups (WG). This document describes the guidelines and procedures for formation and operation of an IETF Working Groups. It describes the formal relationship between a WG and the Internet Engineering and Steering Group (IESG). The basic duties of a WG chair and an IESG Area Director are defined. Interfaces MIB -------------- "Evolution of the Interfaces Group of MIB-II", K. McCloghrie, F. Kastenholz, 10/21/1993, <draft-ietf-ifmib-evolution-04.txt> Abstract not provided. "Management Information Base for Management of Network Connections", K. Rodemann, 10/21/1993, <draft-ietf-ifmib-conntable-00.txt> This memo defines an extension to the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines managed objects used for managing Network Connections. Integration of Internet Information Resources --------------------------------------------- "Resource Transponders", C. Weider, 10/26/1993, <draft-ietf-iiir-transponders-01.txt> Although a number of systems have been created in the last several years to provide resource location and navigation on the Internet, the information contained in these systems must be maintained and updated by hand. This paper describes an automatic mechanism, the resource transponder, for maintaining resource location information. Author's note: This document is being circulated as a research paper; consequently there are no protocol specifications or anything of the sort. I hope that we can go from here and actually get some implementation experience. "A Vision of an Integrated Internet Information Service", C. Weider, P. Deutsch, 10/26/1993, <draft-ietf-iiir-vision-01.txt> This paper lays out a vision of how Internet information services might be integrated over the next few years, and discusses in some detail what steps will be needed to achieve this integration. "Hypertext Markup Language (HTML): A Representation of Textual Information and MetaInformation for Retrieval and Interchange", T. Berners-Lee, D. Connolly, 07/23/1993, <draft-ietf-iiir-html-01.txt, .ps> HyperText Markup Language (HTML) can be used to represent Hypertext news, mail, online documentation, and collaborative hypermedia; Menus of options; Database query results; Simple structured documents with inlined graphics. Hypertext views of existing bodies of information. The World Wide Web (W3) initiative links related information throughout the globe. HTML provides one simple format for throughout the globe. HTML provides one simple format for providing linked information, and all W3 compatible programs are required to be capable of handling HTML. W3 uses an Internet protocol (Hypertext Transfer Protocol, HTTP), which allows transfer representations to be negotiated between client and server, the result being returned in an extended MIME message. HTML is therefore just one, but an important one, of the representations used with W3. HTML is proposed as a MIME content type. "WAIS over Z39.50-1988", M. St. Pierre, J. Fullton, K. Gamiel,, 10/26/1993, <draft-ietf-iiir-wais-00.txt> Abstract not provided. Interactive Mail Access Protocol -------------------------------- "INTERACTIVE MAIL ACCESS PROTOCOL - VERSION 2bis", M. Crispin, 10/01/1993, <draft-ietf-imap-imap2bis-01.txt> The Interactive Mail Access Protocol, Version 2bis (IMAP2bis) allows a client to access and manipulate electronic mail on a server. IMAP2bis is designed to permit manipulations of remote mailboxes as if they were local. IMAP2bis includes operations for creating, deleting, and renaming mailbox folders; checking for new mail; permanently removing messages; setting and clearing flags; RFC 822 and MIME parsing; searching; and selective fetching of message attributes, texts, and portions thereof. IP Over Large Public Data Networks ---------------------------------- "Parameter Negotiation for the Multiprotocol Interconnect", K. Sklower, C. Frost, 09/02/1993, <draft-ietf-iplpdn-para-negotiation-02.txt> This document describes mechanisms for negotiating operational parameters wherever SNAP encapsulation of Internet Protocols is available. For example, it is suitable for use in conjunction with RFC 1294 (Multiprotocol Over Frame Relay) and RFC 1356 (Multiprotocol Interconnect on X.25 and ISDN in the Packet Mode), and potentially others. The mechanisms described here are intended as optional extensions, intended to facilitate interoperation in public networks were preconfiguration may not have been done symmetrically by all parties who wish to exchange information. "Determination of Encapsulation of Multi-protocol Datagrams in Circuit-switched Environments", K. Sklower, 09/02/1993, <draft-ietf-iplpdn-multi-isdn-02.txt> This document enumerates the existing means for transmitting Internet Protocols across public data networks using circuit-mode ISDN, and other switched services. It recommends limiting the choices to the three most common methods, from which one can determine which method is in use by inspection of the packets. The intention is to capture in a slightly more formal way the level of consensus reached at the 24th - 27th IETF meetings. "A Multilink Protocol for Synchronizing the Transmission of Multi-protocol Datagrams.", K. Sklower, 09/02/1993, <draft-ietf-iplpdn-simple-multi-01.txt> This document proposes a method for splitting and recombining datagrams across multiple logical data links. Such facilities are desirable to exploit the potential for increased bandwidth offered by multiple bearer channels in ISDN, yet to do so in such away that minimizes reordering of packets. This is accomplished by means of new PPP options and protocols. This draft incorporates comments arising at the 27th IETF meeting in Amsterdam. IS-IS for IP Internets ---------------------- "Further Integration of IS-IS; Appletalk, IPX, and Other Protocols", R. Perlman, C. Gunner, 06/25/1993, <draft-ietf-isis-atipx-00.txt> This document defines a method of extending the Integrated ISIS protocol (defined in RFC 1195) with routing information from additional protocols -- specifically NetWare IPX and Appletalk. "Routing over Nonbroadcast Multiaccess Links", R. Perlman, C. Gunner, 07/07/1993, <draft-ietf-isis-nbma-00.txt> This document assumes basic familiarity with CLNP, ES-IS, IS-IS, ARP, and IP. The design in this document attempts to minimize routing control traffic and manual configuration. The issues involve judicious use of CLNP addressing whenever possible, protocol differentiation (also sometimes called encapsulation) for coexistence with other protocols running over the NBMA, enabling ESs to find an active IS, enabling ISs to find each other, optimizing routes across NBMA (eliminating double-hopping across NBMA), and efficient and reliable distribution of LSPs (link state packets) across NBMA. "Multiple Levels of Hierarchy with IS-IS", R. Perlman, C. Gunner, 08/09/1993, <draft-ietf-isis-multilevel-routing-00.txt> This paper describes the management, algorithms, and control packet structures necessary to support arbitrary levels of routing hierarchy in IS-IS. Internet School Networking -------------------------- "FYI on Questions and Answers: Answers to Commonly Asked "Primary and Secondary School Internet User" Questions", J. Sellers, 10/05/1993, <draft-ietf-isn-faq-02.txt> The goal of this Internet Draft, produced by the Internet School Networking (ISN) group in the User Services Area of the Internet Engineering Task Force (IETF), is to document the questions most commonly asked about the Internet by those in the primary and secondary school community, and to provide pointers to sources which answer those questions. It is directed at educators, school media specialists, and school administrators who are recently connected to the Internet, who are accessing the Internet via dial-up or another means which is not a direct connection, or who are considering an Internet connection as a resource for their schools. Mail and Directory Management ----------------------------- "Network Services Monitoring MIB", N. Freed, S. Kille, 09/17/1993, <draft-ietf-madman-networkmib-05.txt> There are a wide range of networked applications for which it is appropriate to provide SNMP Monitoring. This includes both TCP/IP and OSI applications. This document defines a MIB which contains the elements common to the monitoring of any network service application. This information includes a table of all monitorable network service applications, a count of the associations (connections) to each application, and basic information about the parameters and status of each application-related association. "Mail Monitoring MIB", N. Freed, S. Kille, 09/27/1993, <draft-ietf-madman-mtamib-06.txt> This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, this memo extends the basic Network Services Monitoring MIB to allow monitoring of Message Transfer Agents (MTAs). It may also be used to monitor MTA components within gateways. "Directory Monitoring MIB", G. Mansfield, S. Kille, 09/15/1993, <draft-ietf-madman-dsa-mib-05.txt> This document defines an experimental portion of the Management Information Base (MIB). It defines the MIB for monitoring Directory System Agents (DSA), a component of the OSI Directory. This MIB will be used in conjunction with the APPLICATION-MIB for monitoring DSAs. MHS-DS ------ "Use of the Directory to support mapping between X.400 and RFC 822 Addresses", S. Kille, 07/07/1993, <draft-ietf-mhsds-supmapping-03.txt, .ps> This document defines how to use directory to support the mapping between X.400 O/R Addresses and mailboxes defined in RFC 1327. "Representing Tables and Subtrees in the Directory", S. Kille, 07/07/1993, <draft-ietf-mhsds-subtrees-03.txt, .ps> This document defines techniques for representing two types of information mapping in the OSI Directory. 1. Mapping from a key to a value (or set of values), as might be done in a table lookup. 2. Mapping from a distinguished name to an associated value (or values), where the values are not defined by the owner of the entry. This is achieved by use of a directory subtree. These techniques were developed for supporting MHS use of Directory, but are specified separately as they have more general applicability. "Use of the Directory to support routing for RFC 822 and related protocols", S. Kille, 07/08/1993, <draft-ietf-mhsds-822dir-03.txt, .ps> This document defines a mechanism to route RFC 822 using the OSI Directory. The basic mechanisms are being developed for routing X.400. These offer a number of benefits relative to the the current mechanisms available for RFC 822 routing. The prime goal of this specification is to provide integrated routing management for sites using both RFC 822 and X.400. This draft document will be submitted to the RFC editor as a protocol standard. Distribution of this memo is unlimited. Please send comments to the author or to the discussion group <mhs-ds@mercury.udev.cdc.com>. "Representing the O/R Address hierarchy in the Directory Information Tree", S. Kille, 07/07/1993, <draft-ietf-mhsds-infotree-03.txt, .ps> This document defines a representation of the O/R Address hierarchy in the Directory Information Tree. This is useful for a range of purposes, including Support for MHS Routing and Support for X.400/RFC 822 address mappings. "A simple profile for MHS use of Directory", S. Kille, 07/08/1993, <draft-ietf-mhsds-mhsprofile-03.txt, .ps> The document ``MHS Use of Directory to support MHS Routing'' describes a comprehensive approach to MHS use of directory to support routing. This document defines a strict subset of this document, which is intended to solve the most pressing problems. It also defines a practical first step for implementation, such that this subset can be deployed prior to fuller implementation. This document does not repeat information in the other document. Duplication would only lead to the possibility of inconsistency. WARNING: This document must be read in the contex of the document it profiles. It is meaningless as a standalone document. This draft document will be submitted to the RFC editor as a protocol standard. Distribution of this memo is unlimited. Please send comments to the author or to the discussion group <mhs-ds@mercury.udev.cdc.com>. "MHS use of Directory to support MHS Routing", Steve Kille, 07/19/1993, <draft-ietf-mhsds-routdirectory-03.txt> This document specifies an approach for X.400 Message Handling Systems to perform application level routing using the OSI Directory. Use of the directory in this manner is fundamental to enabling large scale deployment of X.400. This draft document will be submitted to the RFC editor as a protocol standard. Distribution of this memo is unlimited. Please send comments to the author or to the discussion group <mhs-ds@mercury.udev.cdc.com>. "MHS use of Directory to support MHS Content Conversion", S. Kille, 07/08/1993, <draft-ietf-mhsds-convert-01.txt, .ps> User Agents have various capabilities for support of multimedia messages. To facilitate interworking between UAs of differing capabilities, it is useful for the MTS to be able to perform content conversion. This document specifies an approach for X.400 Message Handling Systems to perform application level routing using the OSI Directory in order to support content conversion. This document assumes MHS use of directory to perfom routing accoreding to ``MHS use of Directory to support MHS Routing''. This draft document will be submitted to the RFC editor as a protocol standard. Distribution of this memo is unlimited. Please send comments to the author or to the discussion group <mhs-ds@mercury.udev.cdc.com>. "Introducing Project Long Bud Internet Pilot Project for the Deployment of X.500 Directory Information in Support of X.400 Routing", H. Alvestrand, K. Jordan, S. Langlois,, 06/21/1993, <draft-ietf-mhsds-long-bud-intro-00.txt> The Internet R&D X.400 community (i.e. GO-MHS) currently lacks a distributed mechanism providing dynamic update and management of message routing information. The IETF MHS-DS Working Group has specified an approach for X.400 Message Handling Systems to perform message routing using OSI Directory Services. The MHS-DS approach has been successfully tested in a number of local environments. This INTERNET--DRAFT describes a proposed Internet Pilot Project that seeks to prove the MHS-DS approach on a larger global scale. The results of this pilot will then be used to draw recommendations for a global scale deployment. Modem Management ---------------- "Modem MIB", L. Brown, R. Roysten, S. Waldbusser,, 10/26/1993, <draft-ietf-modemmgt-mdmmib-00.txt> This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing dial-up modems and similar dial-up devices. This MIB module provides a set of objects that are the minimum necessary to provide the ability to monitor and control those devices, and is consistent with the SNMP framework and existing SNMP standards. Multicast Extensions to OSPF ---------------------------- "Multicast Extensions to OSPF", J. Moy, 07/26/1993, <draft-ietf-mospf-multicast-04.txt, .ps> This memo documents enhancements to the OSPF protocol enabling the routing of IP multicast datagrams. In this proposal, an IP multicast packet is routed based both on the packet's source and its multicast destination (commonly referred to as source/destination routing). As it is routed, the multicast packet follows a shortest path to each multicast destination. During packet forwarding, any commonality of paths is exploited; when multiple hosts belong to a single multicast group, a multicast packet will be replicated only when the paths to the separate hosts diverge. OSPF, a link-state based routing protocol, provides a database describing the Autonomous System's topology. A new OSPF link state advertisement is added describing the location of multicast destinations. A multicast packet's path is then calculated by building a pruned shortest-path tree rooted at the packet's IP source. These trees are built on demand, and the results of the calculation are cached for use by subsequent packets. Please send comments to mospf@gated.cornell.edu. "MOSPF: Analysis and Experience", J. Moy, 07/26/1993, <draft-ietf-mospf-analysis-02.txt> This memo documents how the MOSPF protocol satisfies the requirements imposed on Internet routing protocols by "Internet Engineering Task Force internet routing protocol standardization criteria" ([RFC 1264]). This memo provides information for the Internet community. It does not specify any Internet standard. Distribution of this memo is unlimited. Please send comments to mospf@gated.cornell.edu. Network Access Server Requirements ---------------------------------- "Network Access Server Proposed Requirements Document", J. Vollbrecht, A. Rubens, G. McGregor,, 07/02/1993, <draft-ietf-nasreq-nasrequirements-01.txt> Abstract not provided. Network Information Services Infrastructure ------------------------------------------- "Current NIC Interrelationships", A. Marine, 06/28/1993, <draft-ietf-nisi-nics-00.txt> Recently there have been significant changes in the manner in which Internet information services are provided. The goal of this document is to provide a brief snapshot of the roles and relationships of current Network Information Centers (NICs). Independant Submissions to Internet Drafts ------------------------------------------ "The IP Network Address Translator (Nat)", Paul Francis, Kjeld Egevang, 05/28/1993, <draft-egevang-addrtrans-02.txt> The two most compelling problems facing the IP Internet are IP address depletion and scaling in routing. Long-term and short-term solutions to these problems are being developed. The short-term solution is CIDR (Classless InterDomain Routing). The long-term solutions consist of various proposals for new internet protocols with larger addresses. "A New IP Routing and Addressing Architecture", J.N. Chiappa, 09/23/1993, <draft-chiappa-routing-01.txt> This document presents one possible new IP routing and adressing architecture. By routing and addressing it is meant that part of the overall IP architecture which is responsible for identifying computing nodes, where they are in the Internet, and how to get traffic from one to another. It represents one person's view of a good overall system answer to this question, and is not to be taken as anything more than that. "IDRP for IP", S. Hares, J. Scudder, 10/13/1993, <draft-hares-idrp-05.txt> This memo specifies the adaptation of the ISO Inter-Domain Routing Protocol that enables it to be used as an Inter-Autonomous System routing protocol in the TCP/IP Internet. IDRP with this adaptation will be called "IDRP for IP" in this document. Dual IDRP, that is, a single instance of IDRP that can simultaneously support Inter-Domain/Inter-Autonomous System routing in the TCP/IP and OSI Internets is outside the scope of this document. "Source Demand Routing: Packet Format and Forwarding Specification (Version 1).", Deborah Estrin, Daniel Zappala, Tony Li,, 09/14/1993, <draft-estrin-sdrp-03.txt> This document defines a policy routing protocol for the Internet. "Recommendations for Mail Based Servers", J. Houttuin, 09/28/1993, <draft-houttuin-mailservers-02.txt> This document defines recommendations to be implemented in mail based servers in the Internet and GO-MHS e-mail communities. The requirements only affect the basic behaviour of servers, i.e. it mainly deals with how header fields are handled. Although there is also a clear need for recommendations in the field of end user requirements, such as command syntaxes for archive servers, automatic distribution list subscription, etc., such issues are considered more suitable to be dealt with in a separate document. It is highly desirable that other e-mail networks connected to the Internet also implement these recommendations. "IP and ARP on Fibre Channel (FC)", Y. Rekhter, 04/15/1993, <draft-rekhter-fibre-channel-01.txt> This document specifies a standard method of encapsulating the Internet Protocol (IP) datagrams and Address Resolution Protocol (ARP) requests and replies on FC hardware and protocols. "Routing over Demand Circuits on Wide Area Networks - RIP", G. M. Meyer, 08/24/1993, <draft-meyer-demandrouting-02.txt> Running routing protocols on connection oriented Public Data Networks, for example X.25 packet switched networks or ISDN, can be expensive if the standard form of periodic broadcasting of routing information is adhered to. The high cost arises because a connection has to all practical intents and purposes be kept open to every destination to which routing information is to be sent, whether or not it is being used to carry user data. Routing information may also fail to be propagated if the number of destinations to which the routing information is to be sent exceeds the number of channels available to the router on the Wide Area Network (WAN). This memo defines a generalized modification which can be applied to Bellman-Ford (or distance vector) algorithm information broadcasting protocols, for example IP RIP, Netware RIP or Netware SAP, which overcomes the limitations of the traditional methods described above. The routing protocols support a purely triggered update mechanism on demand circuits on WANs. The protocols run UNMODIFIED on LANs or fixed point-to-point links. "ISO/CCITT and Internet Management Coexistence (IIMC): Translation of Internet MIBs to ISO/CCITT GDMO MIBs (IIMCIMIBTRANS)", L. LaBarre, 08/09/1993, <draft-labarre-internetmib-iso-03.txt, .ps> This document is intended to facilitate the multi-protocol management coexistence and interworking for networks that are managed using the ISO/CCITT Common Management Information Protocol (CMIP) and networks that are managed using the Internet Simple Network Management Protocol (SNMP). This document contains translation and registration procedures that are applicable to translation of Internet MIBs, defined according to the Internet Structure of Management Information (SMI), into ISO/CCITT SMI-defined MIBs. This document also defines and registers generic management information that may be used with the translation procedures to facilitate interoperability. "ISO/CCITT and Internet Management Coexistence (IIMC): Translation of ISO/CCITT GDMO MIBs to Internet MIBs (IIMCOMIBTRANS)", O. Newnan, 06/03/1993, <draft-newnan-isomib-internet-02.txt, .ps> This document is intended to facilitate the use of ISO/CCITT MIBs for integrated management of networks via proxy management of TCP/IP networks that are managed using SNMP. This document provides heuristic procedures that translate managed object specifications from ISO/CCITT Guidelines for Definition of Managed Object (GDMO) templates to Internet MIB macros. Currently, some market segments demand SNMP for customer network management, while others require the ISO/CCITT Common Management Information Protocol (CMIP). The approach defined in this document accommodates both, protecting investment already made in management information specifications and minimizing cost to implement a second protocol where the market requires. This translation is designed to: lose as little functionality as possible in translation; minimize need for human involvement during translation; minimize cost to implement dual protocol and proxy-based applications; and support generic network models that span many computer platforms and network elements. This document in intended to encourage standardization of such an approach and promote consistent usage of MIB definitions, independent of protocol. "ISO/CCITT and Internet Management Coexistence (IIMC): Translation of Internet MIB-II (RFC1213) to ISO/CCITT GDMO MIB (IIMCMIB-II)", L. LaBarre, 08/09/1993, <draft-labarre-iimc-mibii-03.txt, .ps> This document is intended to facilitate the multi-protocol management coexistence and interworking for networks that are managed using the ISO/CCITT Common Management Information Protocol (CMIP) and networks that are managed using the Internet Simple Network Management Protocol (SNMP). This document contains the ISO/CCITT GDMO definition and registration of MIB-II as derived from the Internet MIB-II [RFC1213], according to the procedures defined in "Translation of Internet MIBs to ISO/CCITT GDMO MIBs" [IIMCIMIBTRANS]. In addition, this document includes a translated IPForwarding Table as derived from the Internet definition in [RFC1354]. "ISO/CCITT and Internet Management Coexistence (IIMC): ISO/CCITT to Internet Management Security (IIMCSEC)", L. LaBarre, 08/09/1993, <draft-labarre-iimc-party-03.txt, .ps> This document is intended to facilitate the multi-protocol management coexistence and interworking for networks that are managed using the ISO/CCITT Common Management Information Protocol (CMIP) and networks that are managed using the Internet Simple Network Management Protocol (SNMP). This document defines the end-to-end security architecture, services, and mechanisms for use with ISO/CCITT-Internet proxies. This document also contains the ISO/CCITT GDMO definition and registration of the SNMP Parties MIB, derived from the Internet SNMP Parties MIB [RFC1447] according to the procedures defined in "Translation of Internet MIBs to ISO/CCITT GDMO MIBs" [IIMCIMIBTRANS]. "ISO/CCITT and Internet Management Coexistence (IIMC): ISO/CCITT to Internet Management Proxy (IIMCPROXY)", A. Chang, 08/09/1993, <draft-chang-iimc-proxy-03.txt, .ps> This document is intended to facilitate the use of the ISO/CCITT Common Management Information Protocol (CMIP) for integrated management of networks via proxy management of TCP/IP networks that are managed using Simple Network Management Protocol (SNMP). This document describes an ISO/CCITT to Internet "proxy" which allows interworking between CMIP-based managers and SNMP-based agents. The proxy emulates CMIS service requests by mapping between corresponding ISO/CCITT GDMO and Internet MIB definitions, and generating SNMP message(s) needed to emulate the service. The proxy also emulates CMIS service responses and notifications by converting incoming SNMP response and trap message(s) in a similar fashion. Thus, the proxy appears as a CMIP-based agent to the manager, and as an SNMP-based manager to the agent. The proxy depends on the availability of corresponding MIB definitions translated as described in [IIMCIMIBTRANS]. "DNS NSAP Resource Records", B. Manning, R. Colella, 08/02/1993, <draft-manning-dns-nsap-03.txt> The Internet is moving towards the deployment of an OSI lower layers infrastructure. This infrastructure comprises the connectionless network protocol (CLNP) and supporting routing protocols. Also required as part of this infrastructure is support in the Domain Name System (DNS) for mapping between names and NSAP addresses. This document defines the format of two new Resource Records (RRs) for the DNS, replacing the earlier work in RFC 1348. The RRs defined in this paper allow the DNS to support domain name-to-NSAP and NSAP-to-domain name mappings. The RRs may be used with any NSAP address format. "Randomness Requirements for Security", D. Eastlake, S. Crocker, J. Schiller,, 10/04/1993, <draft-ietf-security-randomness-01.txt> Security systems today are built on increasingly strong cryptographic algorithms that foil pattern analysis attempts. However, the security of these systems is dependent on generating secret quantities for passwords, cryptographic keys, and similar quantities. The use of pseudo-random processes to generate secret quantities can result in pseudo-security. The sophisticated attacker of these security systems will often find it easier to reproduce the environment that produced the secret quantities, searching the resulting small set of possibilities, than to locate the quantities in the whole of the number space. Choosing random quantities to foil a resourceful and motivated attacker is surprisingly difficult. This paper points out many pitfalls in using traditional pseudo-random number generation techniques for choosing such quantities, recommends the use of truly random hardware techniques, provides suggestions to ameliorate the problem when a hardware solution is not available, and gives examples of how large such quantities need to be for some particular applications. "Connection Multiplexing Protocol (CMP)", P. Cameron, J. Bates, 07/01/1993, <draft-cameron-cmp-01.txt> One of the problems with terminal servers attached to a LAN is the large number of small packets they can generate. Frequently, most of these packets are destined for only one or two hosts. CMP is a protocol which allows multiple Telnet and Rlogin connections, between a server and a host, to share a single TCP connection. With simple extensions this can be expanded to include other TCP protocols. "FTP Operation Over Big Address Records (FOOBAR)", D. Piscitello, 07/30/1993, <draft-piscitello-ftp-bigports-02.txt> This paper describes a convention for specifying longer addresses in the PORT command. "Address mapping functions and authorities", J. Houttuin, K. Hansen, S. Aumont,, 05/06/1993, <draft-houttuin-mapauth-00.txt, .ps> This document defines the responsibilities and authorities for defining, collecting and distributing RFC 1327 address mapping rules. It clearly defines the items: mapping function, addressing authority, administrative equivalence as well as a mechanism for registering mapping authorities and administrative equivalence. This mechanism is based on an extension of RFC 1327 mapping rules (during the collection distribution process). No changes to already installed gateway software are required. "Korean Character Encoding for Internet Messages", K. Chon, H. Je Park, U. Choi,, 07/20/1993, <draft-chon-korean-encoding-01.txt> This document describes the encoding method being used to represent the Hangul, Korean character, in both header and body part of the internet electronic mail system. This encoding method was specified in System Development Network (SDN) in 1991, and has since then been used, it has widely spread from SDN to other Korean IP networks. "Endpoint Identifiers: What do they do and why are they a good thing?", D. Hitchcock, 05/27/1993, <draft-hitchcock-eid-00.txt> There has been an ongoing debate on the Big Internet list over the past year over whether abstracting the concept of Endpoint Identifier (EID) from the concept of address which has significance in the topology of the network. This draft attempts to summarize the arguments pro and con as well as some discussion of whether the EID should be in the network layer or elsewhere. This draft also contains a specific proposal for EID format with a discussion of the pros and cons of this choice. "Structured Text Interchange Format (STIF)", D. Crocker, 06/09/1993, <draft-crocker-stif-00.txt, .ps> Various applications need to exchange structured information, such as business-card contact information, bibliographic citations, and structured forms and replies. ASN.1 [ISO87] is a commonly accepted framework for producing binary encoding of information. However, Internet data exchanges often take place in a textual environment, such as electronic mail. In these cases, it would be helpful to have conventions for encoding structured information so that it is entirely legible as text, but sufficiently structured to allow machine processing. This document specifies Structured Text Interchange Format (STIF), a syntax for encoding attribute/value pairs. The pairs can be collected into multi-part sequences and nested sub-lists. The syntax provides for user-defined extensions and for references to data from within sequences and sub-lists. While STIF can be generally compared with ASN.1/BER, it attempts much simpler encoding. In particular, it is strictly text-based and it does not provide for specification of a value's data type. "Encoding for Personal Contact Information (PCI)", D. Crocker, 06/09/1993, <draft-crocker-pci-00.txt, .ps> Extensive use of Internet electronic mail demonstrates a need to be able to communicate various descriptive information about participants. The information ranges from telephone and postal addressing, to an indication of the media supported by their electronic mail and information processing environment. This specification provides a basis for encoding such "PCI" business card information by using the STIF [CROC93] syntax. A MIME Content sub-type is defined for carriage of PCI information. "Hebrew Character Encoding for Internet Messages", H. Nussbacher, Y. Bourvine, 06/16/1993, <draft-nussbacher-hebrew-encoding-00.txt> This document describes the encoding used in electronic mail [RFC822] for transferring Hebrew. The standard devised makes use of MIME [RFC1341] and ISO-8859-8. "Characters and character sets for various languages", H. Alvestrand, 06/21/1993, <draft-alvestrand-lang-char-00.txt> There is a need to have a source of information about the characters that are used in various languages. No such information is currently readily available on the net. This document attempts to fill that void. "Managed Objects for the Internet Group Management Protocol", T. Pusateri, 06/23/1993, <draft-pusateri-igmp-mib-00.txt> This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. In particular it defines objects for managing the Internet Group Management Protocol (IGMP) defined in RFC 1112. "Managed Objects for the IP Multicast Forwarding Table", T. Pusateri, 06/23/1993, <draft-pusateri-ipmulti-mib-00.txt> This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. In particular it defines objects for managing the IP Multicast Forwarding Table. IP Multicast Extensions are defined in RFC 1112. "Routing over Demand Circuits - RIP Protocol Analysis", G. Meyer, 06/28/1993, <draft-meyer-rip-analysis-00.txt> As required by Routing Protocol Criteria, this report documents the key features of Routing over Demand Circuits on Wide Area Networks - RIP and the current implementation experience. "MIME Content-Types for Microsoft Windows", R. Weatherley, 06/30/1993, <draft-weatherley-mswindows-mime-00.txt> This memo registers MIME [RFC-MIME] Content-Types for a number of file formats common to the Microsoft Windows environment. The intention is to aid interoperability between mail systems, and to enumerate possible conversions at gateways. This document does not provide detailed descriptions of individual formats, since published descriptions are already available from other sources, notably [SDK4], and are, in some cases, quite complex. "TELNET MPX option", J. Caradec, M. Mercado, 07/07/1993, <draft-caradec-telnet-mpx-option-00.txt> This Internet Draft specifies a multiplexing protocol for TELNET hosts and devices using the Internet TCP/IP protocol stack. Hosts that exchange TELNET Multiplexing (MPX) information within the TELNET protocol are expected to adopt and implement this protocol. "Definitions of Managed Objects for the Node in Fibre Channel Standard", J. Chu, 07/08/1993, <draft-chu-fibre-channel-mib-00.txt> This memo defines a module of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines the objects for managing the operations of the Node in the Fiber Channel Standard. There is a companion memo that defines the objects for managing the operations of the Fabric in the Fibre Channel Standard. "The Virtual Network Protocol for Host Mobility", F. Teraoka, K. Uehara, 07/22/1993, <draft-teraoka-mobileip-vip-00.txt> This memo describes the general virtual network protocol that provides the transport layer with host migration transparency. This protocol is based on the concept of a `virtual network' and the `propagating cache method'. Basically, this protocol can be applied to any connectionless network layer protocol. This memo also describes two virtual network protocols: `VIP' (Virtual Internet Protocol) and `ISO-VIP'. The former is derived from IP, the network layer protocol of Internet, while the latter is derived from CLNP, the connectionless-mode network layer protocol of ISO. "Internet Authentication Guidelines", N. Haller, R. Atkinson, 09/30/1993, <draft-haller-auth-requirements-01.txt, .ps> The authentication requirements of computing systems and network protocols vary greatly with their intended use, accessibility, and their network connectivity. This document describes a spectrum of authentication technologies and provides guidance to protocol developers on what kinds of authentication might be suitable for what kinds of protocols and applications used in the Internet. "Transport Multiplexing Protocol (TMux)", P. Cameron, D. Crocker, 10/07/1993, <draft-cameron-tmux-01.txt> One of the problems with the use of terminal servers is the large number of small packets they can generate. Frequently, most of these packets are destined for only one or two hosts. TMux is a protocol which allows multiple short transport segments, independent of application type, to be combined between a server and host pair. "Handling of Bi-directional Texts in MIME", H. Nussbacher, 08/26/1993, <draft-nussbacher-mime-direction-01.txt> This document describes the format and syntax of the "direction" keyword to be used with bi-directional texts in MIME. "Packet Forwarding for Mobile Hosts", H. Wada, B. Marsh, 08/20/1993, <draft-wada-packet-forwarding-00.txt> This memo describes a new protocol for mobile internetworking: the Internet Packet Transmission Protocol (IPTP). IPTP provides packet forwarding and host location functions that make mobility transparent to all protocols above IP. IPTP specifies control messages between the networking software on mobile hosts and a special Packet Forwarding Service. Backward compatibility is provided by requiring no modifications to stationary hosts or internetwork routers. To reduce overhead, IPTP provides for lazy propagation of location updates. To enhance performance, routes adapt as mobile hosts move. "SIMPLE NETWORK PAGING PROTOCOL - VERSION 1", A. Gwinn, 08/25/1993, <draft-gwinn-paging-protocol-00.txt> Abstract not provided. "Mapping between X.400 P772 and RFC-822", G. Lunt, J. Onions, 10/26/1993, <draft-onions-x400p772-822-mapping-01.txt> This document describes a method for allowing the exchange of P772 military X.400 mail with RFC-822 text based mail. This allows gateways to convert between the two provided certain criteria are met. "Generic Routing Encapsulation (GRE)", S. Hanks, T. Li, D. Farinacci,, 09/13/1993, <draft-hanks-gre-00.txt> Abstract not provided. "Generic Routing Encapsulation over IPv4 networks", S. Hanks, T. Li, D. Farinacci,, 09/13/1993, <draft-hanks-ip-gre-00.txt> Abstract not provided. "MIME Content-Types For Delivery Status Notifications", K. Moore, 09/17/1993, <draft-moore-mime-delivery-00.txt> This memo defines a message format which may be used by a message transfer agent (MTA) or internetwork mail gateway to report the result of an attempt to deliver a message to one or more recipients. The message format utilizies several MIME content-types which are also defined by this memo. "SMTP Service Extension for Delivery Reports", K. Moore, 09/17/1993, <draft-moore-smtp-drpt-00.txt> This memo defines an extension to the SMTP service whereby the an SMTP client may specify to an SMTP server the conditions under which a delivery report should be generated. "Delivery Report Content-Type for use with MIME", G. Vaudreuil, 09/20/1993, <draft-vaudreuil-mime-delivery-00.txt> The memo defines a MIME content type for the return of delivery reports, service availability, and receipt notifications. This content type is intended to be machine processable while remaining human readable. "Selecting an Indirect Provider", Y. Rekhter, 09/27/1993, <draft-rekhter-select-providers-00.txt> Abstract not provided. "Integrated Network Layer Security Protocol", K. Robert Glenn, 09/28/1993, <draft-glenn-layer-security-00.txt> The Internet has been moving towards a more standardized and open infrastructure to cope with its growing requirements. One requirement of particular interest and importance is that of network security. With the possible addition of CLNP [ISO8473] as a connectionless network protocol for the Internet the most useful solution is an integrated network security protocol that will provide security services and mechanisms for both IP and CLNP. The protocol defined by this Internet Draft is used to provide security services in support of an instance of communication between network layer entities for either IP or CLNP. An attempt is made to keep the functionality as close as possible to [ISO11577]. As a result this specification contains all of the technical complexities and problems of [ISO11577]. Editorial comments are included to address certain technical issues, such as headers ending on word boundaries, type-length-value encoding problems, etc. that may be outside the scope of [ISO11577]. This specification should be viewed as an initial attempt at identifying a protocol that can provide a set of security services for both IPV4 and CLNP "Simple Mobile IP (SMIP)", J. Penners, Y. Rekhter, 10/01/1993, <draft-penners-mobileip-smip-00.txt> Abstract not provided. "Naming and Structuring Guidelines for X.500 Directory Pilots", P. Barker, S. Kille, T. Lenggenhager,, 10/27/1993, <draft-rare-nap-x500naming-01.txt> Deployment of a Directory will benefit from following certain guidelines. This document defines a number of naming and structuring guidelines focused on White Pages usage. Alignment to these guidelines is recommended for directory pilots. The final version of this document will replace RFC 1384. "MIME Multipart/Header-Set", D. Crocker, 10/06/1993, <draft-crocker-headerset-00.txt, .ps> Data often are aggregated with an initial set of descriptor information, followed by some number of user data portions. This specification formalizes the occurrences of such aggregations as a MIME Multipart Content-type. It is intended that MIME processors which are aware of the Header-Set construct will be able to process the user data portions, even when they do not understand the specific header (or descriptor) information which begins the set. "SGML-based Personal Contact Information (SPCI)", C. Adie, 10/12/1993, <draft-adie-spci-00.txt, .ps> This document describes how personal contact information may be exchanged in a structured format suitable for machine processing. The SGML-based Personal Contact Information (SPCI) format can be used to encode personal information of the type which might be found on a business card, in a form which is also suitable for human interpretation. Possible uses of this format include: exchange of personal information in email messages; encoding author information within a document; providing information about a mailing list; as an exchange format for "address book" databases; and providing contact information for a company. The SPCI information is encoded using SGML, and the specification is aligned with the SHAVE rules. A MIME body part type is defined for SPCI information. "SGML-based Hierarchical Attribute/Value Encoding (SHAVE)", C. Adie, 10/12/1993, <draft-adie-shave-00.txt, .ps> The usefulness of attribute/value pairs for conveying information is well established. There is a need for a standard text-based method of representing attribute/value data, which is capable of being easily written and read by humans, and also easily processed by a computer program. Often, such data is required to be transferred in electronic mail messages. This document describes how SGML (Standard Generalized Markup Language) can be used as the basis for such a representation. "MIME Content-types for SGML Documents", E. Levinson, 10/19/1993, <draft-levinson-sgml-00.txt> This document specifies how a specific compound object, a complete SGML document, is to be carried within a MIME message. MIME provides a flexible mechanism for structuring RFC 822 message bodies. To use that mechanism for compound documents requires additional agreements on how the compound document is represented and labelled within the message body. In addition, this document specifies the requirements for using MIME to carry SGML documents within a data stream in conformance with the SGML Document Interchange Format (SDIF). That format provides a mechanism for transferring one or more SGML documents. Subtypes are proposed for the Multipart and Application content types to support SGML documents and SDIF within MIME. Compound documents, including SGML, consist of a number of files, some of which may contain references to other files. Explicit indications of the bindings between the sender's file names and the MIME body parts are needed to re-bind the sender's file names to ones on the recipient's system. A content reference header field makes the bindings explicit. "MIME Content Type for BinHex encoded files", P. Faltstrom, D. Crocker, E. Fair,, 10/14/1993, <draft-faltstrom-macmime2-01.txt, .ps> This memo describes the format to use when sending Apple Macintosh files via MIME [BORE93]. The format is compatible with existing mechanisms for distributing Macintosh files, while allowing non-Macintosh systems access to data in standardized formats. "MIME Content Type for BinHex encoded files", P. Faltstrom, D. Crocker, E. Fair,, 10/15/1993, <draft-faltstrom-macmime2-00.txt, .ps> This memo describes the format to use when sending BinHex4.0 files via MIME [BORE93]. The format is compatible with existing mechanisms for distributing Macintosh files. Only when available software and/or user practice dictates, should this method be employed. It is recommended to use application/applefile for maximum interoperability. "MIME Encapsulation of Macintosh files - MacMIME", P. Faltstrom, D. Crocker, E. Fair,, 10/15/1993, <draft-faltstrom-macmime1-00.txt, .ps> This memo describes the format to use when sending Apple Macintosh files via MIME [BORE93]. The format is compatible with existing mechanisms for distributing Macintosh files, while allowing non-Macintosh systems access to data in standardized formats. "SMTP Service Extensions for Binary Transmission of Large MIME Messages", G. Vaudreuil, 10/20/1993, <draft-vaudreuil-smtp-binary-01.txt> This memo defines an extension to the SMTP service whereby an SMTP client and server may negotiate the use of an alternate DATA command "BDAT" for sending unencoded binary MIME messages. "Internet Architecture Extensions for Shared Media", R. Braden, J. Postel, Y. Rekhter,, 10/18/1993, <draft-braden-shared-media-00.txt> The original Internet architecture assumed that each network is labeled with a single IP network number. This assumption is violated for shared media, such as large public data networks. The architecture still works if this is violated, but some unnecessary host-router and router-router hops may result. This memo discusses alternative approaches to extension of the Internet architecture for efficient use of shared media. "Application/Signature", G. Vaudreuil, 10/18/1993, <draft-vaudreuil-mime-sig-00.txt> The memo defines a MIME content type for the exchange of sender contact information and user agent capability information beyond what is feasable in the RFC822 header. This exchange is generally accomplished by use of a signature trailer appended to the message. These signatures commonly contain address, phone, and email addressing. This document outlines a formalization and extension of the signature concept to provide a machine readable, internationally friendly form to exchange this information. "Row creation with SNMPv1", S. Waldbusser, 10/19/1993, <draft-waldbusser-v1rows-00.txt> Abstract not provided. "SMTP Service Extension for Command Pipelining", N. Freed, 10/20/1993, <draft-freed-smtp-pipeline-00.txt> This memo defines an extension to the SMTP service whereby a server can indicate the extent of its ability to accept multiple commands in a single TCP send operation. Using a single TCP send operation for multiple commands can improve SMTP performance significantly. "SMTP Service Extensions for Command Streaming", G. Vaudreuil, 10/20/1993, <draft-vaudreuil-smtp-stream-00.txt> This memo defines an extension to the SMTP service whereby an SMTP client and server may negotiate the use of a command streaming implementation model for SMTP. This model enables the batching of the all commands between the EHLO and DATA command. This extension significantly reduces the number of packets and round trips to send a message. Batching the MAIL FROM and RCPT TO commands for multiple receipients significantly decreases the protocol processing overhead when sending messsages to multiple receipients. "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", L. Zhang, R. Braden, D. Estrin,, 10/26/1993, <draft-braden-rsvp-00.txt, .ps> This memo describes version 1 of RSVP, a resource reservation setup protocol designed for an integrated services Internet. RSVP provides receiver-initiated setup of resource reservations for multicast or unicast data flows, with good scaling and robustness properties. "A Service Model for an Integrated Services Internet", S. Shenker, D. Clark, L. Zhang,, 10/26/1993, <draft-shenker-realtime-model-00.txt, .ps> The Internet is currently being confronted with service demands from a new generation of applications. Supporting these applications effectively and efficiently will require extending the current Internet "best-effort" service model to one that offers an integrated suite of services. The purpose of this memo is to describe a proposed "core" service model for an integrated services Internet. In the Appendix we discuss the process by which such a service model could be standardized by the IETF. "Integrated Services in the Internet Architecture: an Overview.", R. Braden, D. Clark, S. Shenker,, 10/26/1993, <draft-braden-realtime-outline-00.txt, .ps> This memo discusses a proposed extension to the Internet architecture and protocols to provide integrated services, i.e., to support real-time as well as the current non-real-time service of IP. This extension is necessary to meet the growing need for real-time service for multimedia applications. This memo represents the direct product of recent work by Dave Clark, John Wroclawski, Scott Shenker, Lixia Zhang, Sugih Jamin, Deborah Estrin, Bob Braden, and Shai Herzog, and indirectly draws upon the work of many others. "Multipart/References MIME Content-Type", K. Moore, 10/26/1993, <draft-moore-mime-references-00.txt> This memo defines a new MIME content-type "multipart/references", which can be used to denote a set of MIME contents, of which any one may reference the others by its MIME content-id. This mechanism may be used by presentation languages that wish to be able to reference MIME objects, or by other applications (file transfer, authentication, delivery reports) which need to supply related information about another MIME object. "Introduction to White Pages services based on X.500", P. Jurg, 10/26/1993, <draft-rare-nap-x500intro-00.txt> This document explains why an electronic White Pages service is indispensable for the global electronic communication community. It argues that the International ITU-T X.500 (formerly CCITT) and ISO 9594 standard should be used to set up a global White Pages service. The target group of this document consists of IT managers of organizations that are using electronic communication on a day to day basis. This document should help the IT managers to get the necessary executive commitment to start making available the (address) information of their organization through X.500. "Selecting a Direct Provider", Y. Rekhter, 10/26/1993, <draft-rekhter-direct-provider-00.txt> Within the existing Internet routing architecture/protocols different hosts within a domain (autonomous system) usually can't control the choice of adjacent domains for forwarding of the inter-domain traffic originated by the hosts. In this document we describe a simple mechanism that provides hosts with such control. The proposed scheme can be realised with the existing technology, off-the shelf components, and minor tweaking of forwarding algorithm by border routers. The scheme doesn't require any new routing protocols. "SC6 Documents on Liaison with the IETF in the CIDR Environment", J. Houldsworth, 10/27/1993, <draft-houldsworth-sc6-documents-00.txt> Abstract not provided. Network OSI Operations ---------------------- "An Echo Function for ISO 8473", S. Hares, C. Wittbrodt, 04/23/1993, <draft-ietf-noop-echo-02.txt> This memo defines an echo function for the connection-less network layer protocol. It is intended that the ISO echo function be implemented in all OSI systems in the internet. This document will be submitted for consideration a Proposed Standard. "Essential Tools for the OSI Internet", S. Hares, C. Wittbrodt, 06/07/1993, <draft-ietf-noop-tools-03.txt> This document specifies the following three necessary tools to debug problems in the deployment and maintenance of networks using ISO 8473 (CLNP): - - ping or OSI Echo function - traceroute function which uses the OSI Echo function - routing table dump function These CLNS tools are the basics required for hosts and routers for CLNS network support. It is intended that this document specify the most basic support level required for CLNS hosts and routers. This document should progress along the IETF track for host and router requirements. OSI Directory Services ---------------------- "DSA Metrics", P. Barker, R. Hedberg, 04/30/1993, <draft-ietf-osids-dsa-metrics-01.txt> This document defines a set of criteria by which a DSA implementation may be judged. Particular issues covered include conformance to standards; performance; demonstrated interoperability. The intention is that the replies to the questions posed provide a fairly full description of a DSA. Some of the questions will yield answers which are purely descriptive; others, however, are intended to elicit answers which give some measure of the utility of the DSA. The marks awarded for a DSA in each particular area should give a good indication of the DSA's capabilities, and its suitability for particular uses. "Charting Networks in the Directory", G. Mansfield, T. Johannsen, M. Knopper,, 09/02/1993, <draft-ietf-osids-chart-network-dir-00.txt, .ps> There is a need for a framework wherein the infrastructural and service related information about communication networks can be made accessible from all places and at all times in a reasonably efficient manner and with reasonable accuracy. This document presents a model in which a communication network with all its related details and descriptions can be represented in the X.500 Directory. Schemas of objects and their attributes which may be used for this purpose are presented. The model envisages physical objects and several logical abstractions of the physical objects. "Representing IP Information in the X.500 Directory", T. Johannsen, G. Mansfield, M. Kosters,, 09/02/1993, <draft-ietf-osids-ipinfo-x500-dir-00.txt, .ps> This document describes the objects necessary to include information about IP networks and IP numbers in the X.500 Directory. It extends the work "Charting networks in the Directory" [ND] where a general framework is presented for representing networks in the Diretory by applying it to work of IP network assigning authorities, NICs, as well as other applications looking for a mapping of IP numbers to data of related networks. Furthermore, Autonomous Systems and related routing policy information can be represented in the Directory along with their relationship to networks and organizations. "Connection-less Lightweight Directory Access Protocol", A. Young, 10/27/1993, <draft-ietf-osids-cldap-00.txt> The protocol described in this document is designed to provide access to the Directory while not incurring the resource requirements of the Directory Access Protocol (DAP). In particular, it is aimed at avoiding the elapsed time that is associated with connection-oriented communication and it facilitates use of the directory in a manner analagous to the DNS [6,7]. It is specifically targeted at simple lookup applications that require to read a small number of attribute values from a single entry. It is intended to be a complement to DAP and LDAP [5]. The protocol specification draws heavily on that of LDAP. Open Shortest Path First IGP ---------------------------- "The OSPF NSSA Option", R. Coltun, V. Fuller, 10/20/1993, <draft-ietf-ospf-nssa-option-01.txt> This document describes a new optional type of OSPF area, somewhat humorously referred to as a "not-so-stubby" area (or NSSA). NSSAs are similar to the existing OSPF stub area configuration option but have the additional capability of importing AS external routes in a limited fashion. "OSPF Version 2", J. Moy, 09/20/1993, <draft-ietf-ospf-version2-04.txt, .ps> This memo documents version 2 of the OSPF protocol. OSPF is a link-state routing protocol. It is designed to be run internal to a single Autonomous System. Each OSPF router maintains an identical database describing the Autonomous System's topology. From this database, a routing table is calculated by constructing a shortest-path tree. OSPF recalculates routes quickly in the face of topological changes, utilizing a minimum of routing protocol traffic. OSPF provides support for equal-cost multipath. Separate routes can be calculated for each IP Type of Service. An area routing capability is provided, enabling an additional level of routing protection and a reduction in routing protocol traffic. In addition, all OSPF routing protocol exchanges are authenticated. OSPF Version 2 was originally documented in RFC 1247. The differences between RFC 1247 and this memo are explained in Appendix E. The differences consist of bug fixes and clarifications, and are backward-compatible in nature. Implementations of RFC 1247 and of this memo will interoperate. Please send comments to ospf@gated.cornell.edu. "Guidelines for Running OSPF Over Frame Relay Networks", O. deSouza, M. Rodrigues, 05/03/1993, <draft-ietf-ospf-guidelines-frn-00.txt> This memo specifies guidelines for implementors and users of the Open Shortest Path First (OSPF) routing protocol to bring about improvements in how the protocol runs over frame relay networks. We show how to configure frame relay interfaces in a way that obviates the "full-mesh" connectivity required by current OSPF implementations. This allows for simpler, more economic network designs. These guidelines do not require any protocol changes; they only provide recommendations for how OSPF should be implemented and configured to use frame relay networks efficiently. Privacy-Enhanced Electronic Mail -------------------------------- "MIME-PEM Interaction", S. Crocker, N. Freed, J. Galvin,, 10/26/1993, <draft-ietf-pem-mime-03.txt> This memo defines a framework for interaction between MIME and PEM services. MIME, an acronym for "Multipurpose Internet Mail Extensions", defines the format of the contents of Internet mail messages and provides for multi-part textual and non-textual message bodies. PEM, an acronym for "Privacy Enhanced Mail", provides message encryption and authentication services for Internet mail messages. "An Alternative PEM MIME Integration", J. Schiller, 10/26/1993, <draft-ietf-pem-mime-alternative-00.txt> This document describes a mechanism for providing Privacy Enhanced Mail (PEM) functionality within the context of MIME messages. P. Internet Protocol -------------------- "Pip Header Processing", P. Francis, 08/24/1993, <draft-ietf-pip-processing-02.txt> Pip is an internet protocol intended as the replacement for IP version 4. Pip is a general purpose internet protocol, designed to handle all forseeable internet protocol requirements. This specification defines the Pip header processing for Routers and Hosts. "Pip Identifiers", P. Francis, 06/16/1993, <draft-ietf-pip-identifiers-02.txt> Pip is an internet protocol intended as the replacement for IP version 4. The Pip header defines source and destination ID fields whose primary function it is to identify the source and destination of a Pip packet. While Pip systems treat the IDs as flat for the purpose of identification, it is useful to have hierarchical structure in the ID for other purposes, such as for doing a reverse DNS lookup on the ID. This internet-draft defines the structure of Pip IDs. "Use of DNS with Pip", P. Francis, S. Thomson, 07/06/1993, <draft-ietf-pip-dns-01.txt> Pip is an internet protocol intended as the replacement for IP version 4. Pip is a general purpose internet protocol, designed to handle all forseeable internet protocol requirements. This specification describes the use of DNS to support Pip. Because Pip carries IDs and addresses separately, and because Pip Addresses are variable length, DNS must be modified to support Pip. Also, Pip addresses are more likely to change than IP addresses. To enable DNS to still cache aggressively in the presence of address changes, we propose adding functionality to DNS to allow resolvers to ask for later versions of information when previously returned information is found to be out-of-date. In addition to these necessary modifications, we have chosen to add new information to DNS to support transition and to support Pip features, such as policy routing, mobile hosts and routing through Public Data Networks. Later multicast support will be added as well. "Pip Near-term Architecture", P. Francis, 06/15/1993, <draft-ietf-pip-architecture-01.txt> Pip is an internet protocol intended as the replacement for IP version 4. Pip is a general purpose internet protocol, designed to evolve to all forseeable internet protocol requirements. This specification describes the routing and addressing architecture for near-term Pip deployment. We say near-term only because Pip is designed with evolution in mind, so other architectures are expected in the future. This document, however, makes no reference to such future architectures. "The Multi-Level Path Vector Routing Scheme", B. Rajagopalan, P. Francis, 04/08/1993, <draft-ietf-pip-vector-00.txt> This document describes protocols that are part of the Multi-Level Path Vector (MLPV) routing scheme being developed for use in PIP internets. MLPV is a hierarchical routing scheme. It allows an arbitrary number of levels in the topological hierarchy and arbitrary interconnections within and across levels. Conceptually, the execution of MLPV in a PIP router consists of running multiple, independent instances of a path vector routing algorithm, one for each level of the hierarchy that routes are being computed. This document describes the MLPV topological model and specifies the basic path vector routing schemes used at various levels of the hierarchy. "Pip Address Conventions", P. Francis, 06/11/1993, <draft-ietf-pip-address-conv-00.txt> Pip is an internet protocol intended as the replacement for IP version 4. Pip is a general purpose internet protocol, designed to handle all forseeable internet protocol requirements. This specification is one of a number of documents that specify the operation of Pip. This specification describes the conventions for using the various Pip addresses--the hierarchical unicast address, the class-D style multicast address, the CBT multicast address, and the nearcast address. This specification does not describe how Pip addresses are assigned. "PCMP: Pip Control Message Protocol", P. Francis, 06/11/1993, <draft-ietf-pip-control-msg-00.txt> Pip is an internet protocol intended as the replacement for IP version 4. This specification describes the packets used for various control purposes. "Pip Host Operation", P. Francis, 06/11/1993, <draft-ietf-pip-host-operation-00.txt> Pip is an internet protocol intended as the replacement for IP version 4. Pip is a general purpose internet protocol, designed to handle all forseeable internet protocol requirements. This specification is one of a number of documents that specify the operation of Pip. This specification describes the operation of Pip hosts. In particular, it describes how a Pip host picks among multiple Pip Addresses, and how a Pip host responds to various PCMP Packet Not Delivered (PDN) messages. "IP Independent Transition (IPIT) for Pip", P. Francis, 07/06/1993, <draft-ietf-pip-ipit-transition-00.txt> This document outlines a transition scheme for moving from IP to Pip. While this document discusses Pip in particular, it could be applied to any IPng. The transition scheme discussed here is called IPIT, for IP Independent Transition. It has been developed to address problems with the IPAE transition scheme, after which the previous Pip transition scheme was based. The shortcomings of IPAE stem from its reliance on IP addresses during the first phases of transition. The result is that IP-only hosts will not be able to talk globally to IPng hosts after IP addresses have depleted (they will only be able to talk intra-domain). IPIT allows new Pip systems to talk to IP systems without a globally unique IP address. As a result, IP address depletion is less likely with IPIT, and IP-only hosts will be able to talk to Pip hosts forever. In this sense, IPIT is as much a co-existence scheme as it is a transition scheme. Point-to-Point Protocol Extensions ---------------------------------- "The PPP Internetwork Packet Exchange Control Protocol (IPXCP)", W. Simpson, 07/02/1993, <draft-ietf-pppext-ipxcp-04.txt> The Point-to-Point Protocol (PPP) provides a method for transmitting multi-protocol datagrams over point-to-point links. PPP defines an extensible Link Control Protocol, and proposes a family of Network Control Protocols for establishing and configuring different network-layer protocols. The IPX protocol was originally used in Novell's NetWare products, and is now supported by numerous other vendors. This document defines the Network Control Protocol for establishing and configuring the IPX protocol over PPP. "Compressing IPX Headers Over WAN Media (CIPX)", S. Mathur, M. Lewis, 07/19/1993, <draft-ietf-pppext-cipx-04.txt> This document describes a method for compressing the headers of IPX datagrams (CIPX). With this method, it is possible to significantly improve performance over lower speed wide area network (WAN) media. For normal IPX packet traffic, CIPX can provide a compression ratio of approximately 2:1 including both IPX header and data. This method can be used on various type of WAN media, including those supporting PPP and X.25. "PPP LCP Extensions", W. Simpson, 09/07/1993, <draft-ietf-pppext-lcpext-04.txt> The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP defines an extensible Link Control Protocol (LCP) for establishing, configuring, and testing the data-link connection. This document defines several additional LCP features which have been suggested over the past year. "PPP over ISDN", W. Simpson, 10/14/1993, <draft-ietf-pppext-isdn-03.txt> The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links. This document describes the use of PPP over Integrated Services Digital Network (ISDN) switched circuits. "PPP in Frame Relay", W. Simpson, 10/07/1993, <draft-ietf-pppext-frame-relay-02.txt> The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links. This document describes the use of Frame Relay for framing PPP encapsulated packets. "PPP in X.25", W. Simpson, 10/07/1993, <draft-ietf-pppext-x25-02.txt> The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links. This document describes the use of X.25 for framing PPP encapsulated packets. "PPP over SONET/SDH", W. Simpson, 09/22/1993, <draft-ietf-pppext-sonet-01.txt> The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links. This document describes the use of PPP over Synchronous Optical Network (SONET) and Synchronous Digital Heirarchy (SDH) circuits. "PPP in HDLC Framing", W. Simpson, 09/07/1993, <draft-ietf-pppext-hdlc-framing-02.txt> The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links. This document describes the use of HDLC for framing PPP encapsulated packets. "The Point-to-Point Protocol (PPP)", W. Simpson, 09/07/1993, <draft-ietf-pppext-lcp-main-02.txt> The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP is comprised of three main components: 1. A method for encapsulating multi-protocol datagrams. 2. A Link Control Protocol (LCP) for establishing, configuring, and testing the data-link connection. 3. A family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols. This document defines the PPP organization and methodology, and the PPP encapsulation, together with an extensible option negotiation mechanism which is able to negotiate a rich assortment of configuration parameters and provides additional management functions. The PPP Link Control Protocol (LCP) is described in terms of this mechanism. "PPP Bridging Control Protocol (BCP)", F. Baker, R. Bowen, 10/19/1993, <draft-ietf-pppext-for-bridging-01.txt> The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP defines an extensible Link Control Protocol, and proposes a family of Network Control Protocols for establishing and configuring different network-layer protocols. This document defines the Network Control Protocol for establishing and configuring Remote Bridging for PPP links. "A Multilink Protocol for Synchronizing the Transmission of Multi-protocol Datagrams.", K. Sklower, 09/02/1993, <draft-ietf-pppext-multilink-00.txt> This document proposes a method for splitting and recombining datagrams across multiple logical data links. Such facilities are desirable to exploit the potential for increased bandwidth offered by multiple bearer channels in ISDN, yet to do so in such away that minimizes reordering of packets. This is accomplished by means of new PPP options and protocols. This draft incorporates comments arising at the 27th IETF meeting in Amsterdam. "Requirements for an Internet Standard Point-to-Point Protocol", D. Perkins, 10/07/1993, <draft-ietf-pppext-requirements-01.txt> This document discusses the evaluation criteria for an Internet Standard Data Link Layer protocol to be used with point-to-point links. Although many industry standard protocols and ad hoc protocols already exist for the data link layer, none are both complete and sufficiently versatile to be accepted as an Internet Standard. In preparation to designing such a protocol, the features necessary to qualify a point-to-point protocol as an Internet Standard are discussed in detail. An analysis of the strengths and weaknesses of several existing protocols on the basis of these requirements demonstrates the failure of each to address key issues. Historical Note: This was the design requirements document dated June 1989, which was followed for RFC-1134 through the present. It is now published for completeness and future guidance. "The PPP NetBIOS Frames Control Protocol (NBFCP)", T. Dimitri, 10/20/1993, <draft-ietf-pppext-netbios-fcp-01.txt> The Point-to-Point Protocol (PPP) provides a method for transmitting multi-protocol datagrams over point-to-point links. PPP defines an extensible Link Control Protocol, and proposes a family of Network Control Protocols for establishing and configuring different network-layer protocols. The NBF protocol was originally called the NetBEUI protocol and was used in versions of DOS and OS/2 LAN Manager. It is now used in Microsoft Windows NT and Microsoft Windows for Workgroups. This document defines the Network Control Protocol for establishing and configuring the NBF protocol over PPP. "PPP Reliable Transmission", D. Rand, 10/06/1993, <draft-ietf-pppext-reliable-00.txt> The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links. This document defines a method for negotiating and using Numbered-Mode, as defined by ISO 7776, to provide a reliable serial link. "PPP Stacker LZS Compression Protocol", R. Lutz, 10/20/1993, <draft-ietf-pppext-stacker-00.txt> The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links. The PPP Compression Control Protocol provides a method to negotiate and utilize compression protocols over PPP encapsulated links. This document describes the use of the Stacker LZS data compression algorithm, with single or multiple compression histories, for compressing PPP encapsulated packets. "The PPP Compression Control Protocol (CCP)", D. Rand, 10/26/1993, <draft-ietf-pppext-compression-01.txt> The Point-to-Point Protocol (PPP) provides a standard method of encapsulating multiple protocol datagrams over point-to-point links. PPP also defines an extensible Link Control Protocol. This document defines a method for negotiating data compression over PPP links, and describes the use of several such data compression protocols. "PPP Gandalf FZA Compression Protocol", D. Carr, 10/26/1993, <draft-ietf-pppext-gandalf-00.txt> The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links. The PPP Compression Control Protocol provides a method to negotiate and utilize compression protocols over PPP encapsulated links. This document describes the use of the Gandalf FZA data compression algorithm for compressing PPP encapsulated packets. RIP Version II -------------- "RIP Version 2 Carrying Additional Information", G. Malkin, 10/01/1993, <draft-ietf-ripv2-protocol-00.txt> This document specifies an extension of the Routing Information Protocol (RIP), as defined in RFC 1058 and RFC 1388, to expand the amount of useful information carried in RIP messages and to add a measure of security. A companion document will define the SNMP MIB objects for RIP-2 RFC 1389. "RIP Version 2 MIB Extension", G. Malkin, F. Baker, 10/21/1993, <draft-ietf-ripv2-mibext2-00.txt> This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing RIP Version 2. Routing over Large Clouds ------------------------- "NBMA Next Hop Resolution Protocol (NHRP)", J. Heinanen, R. Govindan, 10/15/1993, <draft-ietf-rolc-nhrp-00.txt> This document describes the NBMA Next Hop Resolution Protocol (NHRP). NHRP can be used by a source terminal (host or router) connected to a Non-Broadcast, Multi-Access link layer (NBMA) network to find out the IP and NBMA addresses of the "NBMA next hop" towards a destination terminal. The NBMA next hop is the destination terminal itself, if the destination is connected to the NBMA network. Otherwise, it is the egress router from the NBMA network that is "nearest" to the destination terminal. Although this document focuses on NHRP in the context of IP, the technique is applicable to other network layer protocols as well. Security Area Advisory Group ---------------------------- "ANSWERS TO FREQUENTLY ASKED QUESTIONS ABOUT TODAY'S CRYPTOGRAPHY", P. Fahn, 10/07/1993, <draft-ietf-saag-cryptography-faq-00.txt> Abstract not provided. Source Demand Routing --------------------- "Source Demand Routing Policy Language", T. Li, 06/21/1993, <draft-ietf-sdr-pl-00.txt> This document defines a policy language for use with the SDRP policy routing protocol for the Internet. "Source Demand Routing: Route Setup", D. Estrin, D. Zappala, T. Li,, 06/23/1993, <draft-ietf-sdr-route-setup-00.txt> This document is a supplement to the internet draft "Source Demand Routing: Packet Format and Forwarding Specification". "BGP SDRP_SPEAKERS Attribute", K. Varadhan, 09/13/1993, <draft-ietf-sdr-speakers-attribute-00.txt> This document specifies an attribute to be added to BGP-4 to allow SDRP speakers in different domains to identify one another through BGP-4. Simple Internet Protocol ------------------------ "SIP-RIP", G. Malkin, C. Huitema, 06/29/1993, <draft-ietf-sip-rip-01.txt> This document specifies a routing protocol, based on the Routing Information Protocol (RIP), for the Simple Internet Protocol (SIP). A companion document will define the SNMP MIB objects for SIP-RIP (TBD). "SIP Program Interfaces for BSD Systems", R. Gilligan, 04/05/1993, <draft-ietf-sip-bsd-api-00.txt> In order to implement the Simple Internet Protocol (SIP) in an operating system based on 4.x BSD, changes must be made to some of the application program interfaces (APIs). TCP/IP applications written for BSD-based operating systems have in the past enjoyed a high degree of portability because most of the systems derived from BSD provide the same API, known informally as "the socket interface". We would like the same portability to be possible with SIP applications. This memo presents a set of changes to the BSD socket API to support SIP. The changes include a new data structure to carry 64-bit SIP addresses, a new name to address translation library function, new address conversion functions, and some new setsockopt() options. The changes are designed to be minimal and to provide source and binary compatibility for existing applications. "Administrative Allocation of the 64-bit Number Space", W. Simpson, 04/19/1993, <draft-ietf-sip-64bit-plan-00.txt> SIP uses a numbering space of 64 bits, to replace the 32 bit space used in the current IP. This document specifies an administrative allocation plan wherein the numbering space is efficiently divided into continents, clusters and countries. Space is reserved for end-point identifier, metropolitan and provider assignment schemes to exist in parallel. Special consideration is given to the interaction of these schemes with the inverse function of the domain name service. "SIP System Discovery", W. Simpson, 06/09/1993, <draft-ietf-sip-discovery-02.txt> This document specifies ICMP messages for the identification and location of adjacent SIP systems. This is intended to replace ARP, ICMP Router Advertisement, ICMP Redirect, ICMP Information, ICMP Mask, and OSPF Hello in the SIP environment. There are also elements of the OSI ES-IS and IS-IS Hello. "SIP addresses in the domain name service Specifications", C. Huitema, 06/11/1993, <draft-ietf-sip-dnss-00.txt> This document defines the conventions for storing 64 bits SIP addresses and the corresponding reverse records in the domain name service. This document is an output of the SIP working group. It defines a complement to the RFC-1035, "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION". "Simple Internet Protocol Plus (SIPP): Overview of Routing and Addressing Extensions to SIP", S. Deering, P. Francis, R. Govindan,, 10/06/1993, <draft-ietf-sip-overview-00.txt> Abstract not provided. SNA DLC Services MIB -------------------- "Definitions of Managed Objects for SNA Data Link Control", J. Hilgeman, S. Nix, A. Bartkey,, 10/14/1993, <draft-ietf-snadlc-sdlc-mib-00.txt> This Internet-Draft defines an extension to the Management Information Base (MIB) for use with SNMP-based network management. In particular, it defines objects for managing the configuration, monitoring and control of data link controls in an SNA environment. This draft identifies managed objects for SNA Synchronous Data Link Control (SDLC) links only. This memo does not specify a standard for the Internet community. "Definitions of Managed Objects for SNA Data Link Control", J. Hilgeman, S. Nix, A. Bartkey,, 10/19/1993, <draft-ietf-snadlc-mib-00.txt> This Internet-Draft defines an extension to the Management Information Base (MIB) for use with SNMP-based network management. In particular, it defines objects for managing the configuration, monitoring and control of data link controls in an SNA environment. This draft identifies managed objects for SNA Synchronous Data Link Control (SDLC) links only. This memo does not specify a standard for the Internet community. SNA NAU Services MIB -------------------- "Definitions of Managed Objects for SNA NAUs", Z. Kielczewski, K. Shih, 08/02/1993, <draft-ietf-snanau-snamib-00.txt> This Internet-Draft defines an extension to the Management Information Base (MIB) for use with SNMP-based network management. In particular, it defines objects for managing the configuration, monitoring and control of Physical Units (PUs) and Logical Units (LUs) in an SNA environment. PUs and LUs are two types of Network Addressable Units (NAUs) in the logical structure of an SNA network. NAUs are the origination or destination points for SNA data streams. This draft identifies managed objects for SNA Node Type 2.0 and LUs 0, 1, 2, 3. This memo does not specify a standard for the Internet community. Service Location Protocol ------------------------- "Service Location Protocol", J. Veizades, S. Kaplan, 10/19/1993, <draft-ietf-svrloc-protocol-02.txt> The service location protocol provides a framework for the discovery and selection of network services. It relies on multicast support at the network layer of the protocol stack it is using. It does not specifically rely upon the TCP/IP protocol stack but makes use of concepts that are found in most TCP/IP protocol implementations. Traditionally, users find services using the name of a network host (a human readable text string) which is an alias for a network address. The service location protocol eliminates the need for a user to know the name of a network host supporting a services. Rather, the user supplies a set of attributes which describe the services. The services location protocol allows the user to bind this description to the network address of the service. TCP Large Windows ----------------- "TCP Extensions for High Performance: An Update", R. Braden, 06/23/1993, <draft-ietf-tcplw-extensions-00.txt> This memo is a contribution to the TCP Large Windows (TCPLW) Working Group. It presents some suggested modifications to RFC-1323, which defined TCP extensions to improve performance over large bandwidth*delay product paths and to provide reliable operation over very high-speed paths. TELNET ------ "Telnet Authentication and Encryption Option", Dave Borman, 04/08/1993, <draft-ietf-telnet-encryption-02.txt> This document defines an option for encrypting telnet sessions. "Telnet Environment Option", S. Alexander, 10/08/1993, <draft-ietf-telnet-envmnt-option-02.txt> This document specifies a mechanism for passing environment information between a telnet client and server. Use of this mechanism enables a telnet user to propagate configuration information to a remote host when connecting. This document corrects some errors in RFC 1408. In order to ensure future interoperability, a new option number has been assigned to the environment option by this document. This document is intended to replace RFC 1408 as a Proposed Standard. "Telnet Environment Option Interoperability Issues", D. Borman, 04/08/1993, <draft-ietf-telnet-interoperability-00.txt> RFC 1408, the specification for the Telnet Environment Option, specifies definitions for VAR and VALUE that are reversed from the BSD implementation of the Telnet Environment option. Since the BSD implementation was the reference implementation that the RFC was supposed to document, and is the base for many existing implementations, there exists an interoperability problem between implementations with conflicting definitions for VAR and VALUE. This document describes a method for allowing implementors to ensure that their implementation of the Environment option will be interoperable with as many other implementations as possible, by providing a set of heuristics that can be used to help identify which definitions for VAR and VALUE are being used by the other side of the connection. "TELNET Transfer Control Option", S. Denton, 06/22/1993, <draft-ietf-telnet-transfer-option-00.txt> This memo describes a Telnet option that allows servers to direct clients to re-connect at a specified address. This is useful for distributed servers, such as library databases. It also allows servers which implement load-sharing to indicate a less loaded server to the client. This option allows retargeting to be implemented transparently to the user. Minimal OSI Upper-Layers ------------------------ "Octet sequences for upper-layer OSI to support basic communications applications", P. Furniss, 10/12/1993, <draft-ietf-thinosi-cookbook-01.txt> This document specifies those elements of the OSI upper-layer protocols (Session, Presentation and ACSE) needed to support applications with "basic communications requirements". These include OSI application protocols such as X.400 P7 and Directory Access Protocol, and "migrant" protocols, originally defined for use over other transports. The upper-layer protocol elements are specified in this document as the particular octet sequences that comprise an "envelope" around the application protocol's data. It therefore independent, as a document, from the OSI base standards, although an implementation based on this document will be able to interwork with an implementation based on the base standard, when both are being used to support an appropriate application protocol. Telnet TN3270 Enhancements -------------------------- "TN3270 Enhancements", B. Kelly, 10/05/1993, <draft-ietf-tn3270e-enhancements-02.txt> This document describes a protocol that more fully supports 3270 devices than do the existing tn3270 practices. Specifically, it defines a method of emulating both the terminal and printer members of the 3270 family of devices via Telnet; it provides for the ability of a Telnet client to request that it be assigned a specific device-name (also referred to as "LU name" or "network name"); finally, it adds support for a variety of functions such as the ATTN key, the SYSREQ key, and SNA response handling. This protocol would be negotiated and implemented under a new Telnet Option and would be unrelated to the Telnet 3270 Regime Option as defined in RFC 1041. "TN3270 Extensions for LUname and Printer Selection", C. Graves, 07/28/1993, <draft-ietf-tn3270e-luname-print-00.txt> This document describes protocol extensions to TN3270. There are two extensions outlined in this document. The first defines a way by which a TN3270 client can request a specific device (LUname) from a TN3270 server. The second extension specifies how a TN3270 printer device can be requested by a TN3270 client and the manner in which the 3270 printer status information can be sent to the TN3270 server. Discussions and suggestions for improvements to these enhancements should be sent to the TN3270E Working Group mailing list TN3270E@list.nih.gov . These extensions will be called TN3287 in this document. This information is being provided to members of the Internet community that want to support the 3287 data stream within the TELNET protocol. The distribution of this memo is unlimited. "TN3270 Current Practices", J. Penner, 10/18/1993, <draft-ietf-tn3270e-current-pract-02.txt> This document describes the existing implementation of transferring 3270 display terminal data using currently available telnet capabilities. The name traditionally associated with this implementation is TN3270. Information is provided to aid in the implementation of TN3270 servers as well as client terminal emulators. The following areas pertaining to TN3270 implementations are covered in this document: 1. the telnet options negotiated to transition from a NVT ASCII state to a TN3270 state ready to process incoming 3270 data stream commands 2. the method for sending and receiving 3270 data 3. the method of handling some special keys known as SYSREQ and ATTN using current available telnet commands. 4. the events that will transition a TN3270 session back to an NVT session Trusted Network File Systems ---------------------------- "A Specification of Trusted NFS (TNFS) Protocol Extensions", Fred Glover, 03/01/1993, <draft-ietf-tnfs-spec-03.txt> Additional functionality has been developed for UNIXr systems to address the TCSEC requirements for trusted systems. New requirements are driving efforts to develop interoperable, networked solutions for trusted UNIX environments. A specific approach for addressing TCSEC MLS requirements is identified in the CMW requirements document. Developing support for network interoperability among MLS classified systems is a primary goal of the trusted UNIX community. TP/IX ----- "Initial AD Assignment Plan", R. Ullmann, 06/30/1993, <draft-ietf-tpix-adplan-01.txt> This memo presents an initial plan for the assignments of Administrative Domain numbers (ADs) for version 7 of the Internet Protocol. The objective is to use a very small amount of space in the numbering system, while providing the necessary distribution of authority. "Transit Policy Routing in TP/IX", R. Ullmann, 06/30/1993, <draft-ietf-tpix-transit-01.txt> Abstract not provided. "TCP version 7 options", R. Ullmann, 06/30/1993, <draft-ietf-tpix-tcpopt-00.txt> Abstract not provided. TCP/UDP Over CLNP-Addressed Networks ------------------------------------ "Use of ISO CLNP in TUBA Environments", David Piscitello, 07/30/1993, <draft-ietf-tuba-clnp-04.txt> This document describes the use of CLNP to provide the lower-level service expected by Transmission Control Protocol and User Datagram Protocol. CLNP provides essentially the same datagram service as Internet Protocol, but offers a means of conveying bigger network addresses (with additional structure, to aid routing). While the protocols offer nearly the same services, IP and CLNP are not identical. This document describes a means of preserving the semantics of IP information that is absent from CLNP while preserving consistency between the use of CLNP in Internet and OSI environments. This maximizes the use of already-deployed CLNP implementations. Uninterruptible Power Supply ---------------------------- "UPS Management Information Base", J. Case, 10/26/1993, <draft-ietf-upsmib-01.txt> This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it described managed used for managing it defines objects for managing uninterruptible power supply (UPS) systems. Uniform Resource Identifiers ---------------------------- "Uniform Resource Locators", T. Berners-Lee, 07/20/1993, <draft-ietf-uri-url-01.txt, .ps> Many protocols and systems for document search and retrieval are currently in use, and many more protocols or refinements of existing protocols are to be expected in a field whose expansion is explosive. These systems are aiming to achieve global search and readership of documents across differing computing platforms, and despite a plethora of protocols and data formats. As protocols evolve, gateways can allow global access to remain possible. As data formats evolve, format conversion programs can preserve global access. There is one area, however, in which it is impractical to make conversions, and that is in the names and addresses used to identify objects. This is because names and addresses of objects are passed on in so many ways, from the backs of envelopes to hypertext objects, and may have a long life. This paper discusses the requirements on a universal syntax which can be used to refer to objects available using existing protocols, and may be extended with technology. It makes a recommendation for a generic syntax, and for specific forms for "Uniform Resource Locators" (URLs)of objects accessible using existing Internet protocols. "Uniform Resource Names", C. Weider, P. Deutsch, 10/19/1993, <draft-ietf-uri-resource-names-01.txt> A Uniform Resource Name (URN) is an identifier which can be used to uniquely identify a resource, and is designed to provide persistent naming for networked objects. This name would stay the same no matter what the current location(s) of the object was. Whois and Network Information Lookup Service -------------------------------------------- "Architecture of the Whois++ Index Service", C. Weider, J. Fullton, S. Spero,, 10/27/1993, <draft-ietf-wnils-whois-02.txt> The authors describe an architecture for indexing in distributed databases, and apply this to the WHOIS++ protocol. The WHOIS++ directory service [Deutsch, et al, 1992] is intended to provide a simple, extensible directory service predicated on a template-based information model and a flexible query language. This document describes a general architecture designed for indexing distributed databases, and then applys that architecture to link together many of these WHOIS++ servers into a distributed, searchable wide area directory service. "Whois and Network Information Lookup Service Whois++", J. Gargano, K. Weiss, 07/06/1993, <draft-ietf-wnils-whois-lookup-00.txt> Abstract not provided. X.400 Operations ---------------- "Operational Requirements for X.400 Management Domains in the GO-MHS Community", Robert Hagens, Alf Hansen, 10/15/1993, <draft-ietf-x400ops-mgtdomains-ops-06.txt> This document specifies a set of minimal operational requirements that shall be implemented by all Management Domains (MDs) in the Global Open MHS Community (GO-MHS). This document defines the core operational requirements; in some cases, technical detail is handled by reference to other documents. The GO-MHS Community is defined as all organizations which meet the requirements described in this document. "Postmaster Convention for X.400 Operations", C. A. Cargille, 07/19/1993, <draft-ietf-x400ops-postmaster-02.txt> Both RFC822 and 1173 (Host Requirements) require that the email address "postmaster" be supported at all hosts. This paper extends this concept to X.400 mail domains which have registered RFC1327 mapping rules (and therefore which appear to have normal RFC822-style addresses). It also requires supporting a postmaster address at the ADMD and PRMD levels. "Assertion of C=US; A=IMX", E. Stefferud, 06/07/1993, <draft-ietf-x400ops-admd-02.txt> This document establishes an Internet Based X.400 Administrative Management Domain (ADMD) with the name "A=IMX", for use in the United States of America (C=US), according to the applicable rules of CCITT Recommendations and ISO Standards, and in keeping with existing regulatory practices in the United States of America. It also establishes a naming authority under the Internet Assigned Numbers Authority (IANA) to register and openly publish Private Management Domain (PRMD) names subordinate to A=IMX under C=US. "Mail based file distribution Part 1: Dialog between two nodes", M. Kaittola, 07/06/1993, <draft-ietf-x400ops-tbl-dist-part1-01.txt> Mapping between X.400 and Internet mail and X.400 routing are normally done using a table-based approach. In practise tables are normal (ASCII) files. In order to function properly tables must be coordinated carefully. One major problem is the lack of automated procedures. This memo - together with it's companion document - proposes one possible solution. This memo discusses the transactions between two nodes, while the companion document discusses the over-all structure aspects. The same solution can be used to transport binary files. This way it is possible to mirror an entire archive with an e-mail only connectivity. "Mail based file distribution Part 2: Over-all structure", M. Kaittola, 07/06/1993, <draft-ietf-x400ops-tbl-dist-part2-01.txt> Mapping between X.400 and Internet mail and X.400 routing are normally done using a table-based approach. In practise tables are normal (ASCII) files. In order to function properly tables must be coordinated carefully. One major problem is the lack of automated procedures. This memo - together with it's companion document - proposes one possible solution. This memo discusses the over-all structure aspects, while the companion document discusses the transactions between two nodes. The same solution can be used to transport binary files. This way it is possible to mirror an entire archive with an e-mail only connectivity.